This PR fixes the original test of eclipse-xtext#2921 to effectively recreate the original problem of eclipse-xtext#2920

I mean that, without the patched XtextBuilder the test fails, with the patched XtextBuilder it succeeds.

The idea is to create a fictitious additional language extension, buildertestlanguageGH2920, and add some extension points in plugin.xml for this language extension, by using a custom executable extension factory and introducing a new customizable activator that, for this "language", redefines the creation of JdtHelper to always return false when asked whether isJavaCoreAvailable.

@stephan-herrmann note that I also slightly modify the way the assertions are performed: in your original test the assertions were made during the build. When they fail, the test ends with an error just saying that the build has failed (this is due to the AssertionError being wrapped in a CoreException being wrapped in a OperationCancelledException). The assertion failure is only printed on the console. This makes it hard to understand it. Now, the possible offending resource descriptions are only collected during the build, and the assertions are made outside the build. This way, when the test fails we get a proper failure message.

@szarnekow I hope this solution makes sense, it took me some time to understand how to inject these customizations only for this test :)